Telephony devices such as Session Initiation Protocol (SIP) telephones need significant configuration in order to operate. Various systems exist, such as the SIP Provisioning Server available from Metaswitch Networks Ltd of 100 Church Street, Enfield, EN2 6BQ, UK, to allow a service provider to remotely manage the configuration of a SIP telephone on behalf of a user. Typically, this involves a SIP client running on the telephone retrieving one or more files containing its configuration from a central system such as the SIP Provisioning Server. Usually, one of the retrieved configuration files contains the SIP credentials for the client to use. For hard telephones, the file is usually identified using the Media Access Control (MAC) address of the telephone that is to be configured. For example, the file may be named 001122334455.cfg.
In an insecure provisioning solution design, an attacker that correctly determines, or even guesses, the filename of the configuration for a particular user can obtain the configuration file and thereby make fraudulent calls using the SIP credentials. This is particularly easy if the attacker can discover the MAC address of the user's telephone. The attacker may be able to do this by, for example, physically accessing the telephone, the Local Area Network (LAN) in which the telephone is connected, or on discarded packaging. It is, in any case, not difficult for an attacker to determine candidate MAC addresses because blocks of MAC addresses are assigned to particular phone vendors, and so the search space is relatively small.
Various mechanisms are available that can provide secure provisioning, each with their own merits and limitations.
One existing mechanism relies on the use of a manufacturer firmware secret in which configuration files are encrypted and can be decrypted using a key stored in the telephone. Although configuration files may be encrypted, the configuration files may be protected by a master key in the telephone's firmware. One security concern with this approach is that any publication of the details of the encryption algorithm including the master key would compromise all deployments of such telephones. A more practical limitation with this approach is that it is very specific to the particular vendor and would require custom development work on a provisioning server to integrate the vendor-specific encryption tools.
Another existing mechanism relies on the use of a pre-configured secret. Telephones are configured with the secret (for example a decryption key) prior to shipping to the customer premises. This mechanism requires the service provider (or their agent) to perform a secure “staging” step which typically involves unboxing the phones supplied from the vendor. This significantly increases the cost of deploying these phones in a secure manner. The staging step provides an opportunity for unauthorized disclosure of the secret, potentially compromising the overall security of the deployment. Furthermore, if a deployed phone ever loses its secret (for example if the user returns it to factory default), the phone needs to be returned to the service provided to be re-staged. Although phone vendors tend to use “standard” encryption algorithms, they tend to choose different algorithms (for example 3DES, AES etc.), increasing the vendor-specific work required on the provisioning server.
Another mechanism, is to collect user credentials. This solution is currently used with CommPortal Communicator, available from Metaswitch Network Ltd, and requires that the SIP client locally implement a mechanism to collect credentials from the user. However, many hard phones do not offer this capability in a form in which it is easy for a user to enter this information. For example, the user may be required to connect the phone to a network, identify the IP address assigned to the phone, enter this IP address into a web browser running on a computer connected to the same network, log into a configuration application running on the phone using a default password and navigate to the relevant fields before the user credentials can be entered.
Another way to provide secure provisioning relies on the use of client-side certificates. Some vendors program a unique certificate into the phone during manufacture which the server can use to verify that the request has actually originated from the device with the relevant MAC address. This potentially offers good levels of security, however there are some practical limitations. Few phone vendors support this in practice as it requires hardware support in the phone to store the certificate and complicates the manufacturing process. Typically, the client certificate is verified using mechanisms provided by HTTPS. In some deployment scenarios, a reverse proxy may be deployed between the phone and the provisioning server. Since the reverse proxy terminates the HTTPS flow, additional integration is needed between the reverse proxy and the provisioning server, which tends to be specific to the reverse proxy.
Another mechanism is to supply the user with credentials in a physical module such as a SIM card. Whilst this mechanism is widely used in mobile networks, it is not supported by typical “wireline” hard phones.
US-A1-2011/0067096 describes a system and method for providing secure configuration file exchange A Voice over Internet Protocol (VoIP) device receives an encrypted first configuration file from a server using a default Uniform Resource Locator (URL), which is decrypted using a default key stored in the VoIP device. The default URL and the default key are updated with a new URL and a new key stored in the first configuration file. The VoIP device receives an encrypted second configuration file from the server using the new URL, decrypts the second configuration file using the new key and applies a set of profile parameters stored in the second configuration file to provide network service from the server to a customer premise equipment (CPE) communicatively coupled to the VoIP device. Thus, this system relies upon the VoIP device already having the default key stored in it in advance to be able to decrypt the first configuration file.
The existing systems described above typically rely upon the telephone that is being provisioned supporting certain functions and also no single security mechanism is widely supported across phone vendors. This means that a provisioning server needs to implement different security strategies for each different phone vendor.
It would therefore be desirable to be able to provide improvements in remotely managing the remote configuration of a telephony device. In particular, it would be desirable to provide improvements in remotely managing the configuration of a telephony device in a secure manner, which places minimal requirements on the telephony device being configured.